1. Technical Field
The invention relates to web-based applications. More particularly, the invention relates to self-customizing and maintaining the navigation history of a web application.
2. Description of the Prior Art
A typical business web application contains many logical modules. For example an Electronic Discovery Management System (EDMS) application may contain a set of pages responsible for editing information about legal matter, sending hold notices, maintaining data sources, maintaining lists of employees, etc.
Very often, there is a need to temporarily leave one module of the application in order to perform certain activities in another module and then navigate back. For example an EDMS user might start editing recipients of a hold notice at a hold notice module, then go to list of employees at a different module, copy a few people into a clipboard, then return back to the hold notice module, and paste the list from the clipboard.
In this disclosure, a module is a set of related pages logically related to each other. For example a Hold Notice module may contain a list of holds, a hold edit page, a hold view page, a view and edit recipients pages, etc. Usually it is fast and easy for a user to navigate within the module and no extra navigation mechanisms are necessary. However, when it comes to navigation between modules, this is not the case. For example, if a user wants to navigate to a matter view page from outside the matter module the user needs to:                Click “Matters” top menu item and get the matter search page;        Type in matter search criteria and click “Search”;        Find the matter within search results; and        Click on the matter list item.        
Likewise, navigation to the data source view page may have similar steps. Therefore it would be desirable to somehow navigate directly from the current data source to the current matter without performing these steps again and again.
It has been found that, typically, when a user needs to navigate back, such as in the example above from the People module to the Hold Notices module, the following navigation mechanisms are offered by prior art applications:
1. Browser back button (with or without an associated Back button menu.) The user clicks the Back button and the browser displays pages from its history store until the user finds and selects the right page. This solution has the following drawbacks:
                This mechanism works well when all the pages are stateless, i.e. when the state of the page is fully defined by input parameters, and there is no page expiration. This mechanism does not work well for stateful pages, i.e. where a page needs to read a value of some state variable such as cookie or session variable to understand what content to display. To achieve more robust functionality in such situations application developers introduce page expiration so that the user doesn't get unpredictable results when clicking the Back button;        Page names in the browser history typically don't provide enough context for the user to decide to which page she wants to navigate;        The browser history doesn't survive a browser restart operation.        The “stack” oriented design. Suppose that the user navigated from page A to page B, then clicked the “back” button to navigate back to page A, then navigated to page C. The browser history stack remembers only page A and page C. The browser history stack drops page B from its memory because page B is not on the current navigation path of the browser, even if page B is very important for a user.        Displaying useless navigation options. Because the browser cannot understand the importance (or lack thereof) of certain pages within an application, the browser has to store all the pages in history regardless of whether such pages are important or not.        Lack of de-duplication. When a user navigated multiple times from one page to another, e.g. from page A->page B->page A->page C->and so forth, the history contains as many entries as times the browser hit a particular page. This may result in lots of redundant entries in navigation history. Redundant entries may prevent other useful history entries from showing up because history menus have finite size.        
FIG. 1 shows a typical back button menu with drawbacks such as: cryptic titles, multiple entries for the same page, and missing entries when the page is not on a current navigation path (not shown, but implied), according to the prior art.
FIG. 2 shows an example navigation path, according to the prior art. The numbers, 1-10, show the sequence of navigation steps by a user. The dashed pages (Useful page2.jsp, Useful page4.jsp, and Useful page5.jsp) show the pages which are purged from the navigation history because they are not on a main navigation path, i.e. steps (1), (4), (9), and (10). The rest of the pages are displayed by the history menu.
2. Provide a “Back” link on an application page which points to the page from where the user came. For example, on an employee search result page, provide a link back to the Hold Notice recipient edit page. Major disadvantages of this approach include:
                Adding many more integration points between parts of applications, the addition of which results in a lot of extra code and greater testing costs;        Developers must know in advance to where any user can possibly return from a given page; and        There is only one page to where the user can return.3. Provide navigation “breadcrumb” within application a menu allowing the user to easily navigate back to previous steps. One major disadvantage of this approach is the focus on the “stack”, i.e. the same drawback as mentioned in item 1 above.4. No easy history navigation at all. For example, in EDMS if the user needs to return back to a Hold Notice Recipients page from, e.g., a data source detail page, she may have to go to the List of Matters page, find a matter, click on the matter record, choose “Hold notices” from the submenu, find a hold notice and click a “Recipients” link. Needless to say, this option is very time consuming and most likely annoying for a user.        
None of the above solutions are particularly good. There is a need for a navigation solution which is free from above mentioned drawbacks, yet doesn't have too many drawbacks of its own.